home *** CD-ROM | disk | FTP | other *** search
/ IRIX 5.3 for Indy R4400 / IRIX 5.3 for Indy R4400 175MHz.img / relnotes / explorer / ch4.z / ch4
Text File  |  1995-02-28  |  24KB  |  661 lines

  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        4.  _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s
  9.  
  10.        This chapter describes the known problems with release 2.2.2
  11.        of IRIS Explorer and, where known, ways to work around them.
  12.  
  13.        4.1  _M_a_p__E_d_i_t_o_r
  14.  
  15.           +o Explorer, because it is a multiprocess application, can
  16.             consume a substantial number of processes and file
  17.             descriptors, depending on its use.
  18.  
  19.           +o When modules that contain file browser widgets are run
  20.             remotely, the widgets show files that are available
  21.             only on the local machine.  To correctly enter a remote
  22.             filename in this case, the name must be correctly typed
  23.             into the text field without the benefit of the browsing
  24.             capability. All Explorer modules have been modified to
  25.             remove the file browser from the control panel, moving
  26.             it instead to the module menu bar.
  27.  
  28.           +o The ``Interrupt'' item on module menus interrupts user
  29.             functions with the UNIX signal SSSSIIIIGGGGUUUUSSSSRRRR1111.  User functions
  30.             must not interfere with the capturing of this signal.
  31.             Modules that are multithreaded, such as the image
  32.             processing modules on multiprocessors, will not
  33.             properly clean up the parallel threads when interrupted
  34.             with this feature, and may fail on subsequent firings.
  35.  
  36.           +o Modules that have parameter functions on their inputs
  37.             cannot be duplicated or copied from the cut buffer
  38.             without an error message complaining about can't find
  39.             upstream module.
  40.  
  41.           +o The (destroy) and (disconnect) scripting language
  42.             commands are not synchronous.  Hence, if you re-create
  43.             a link or module immediately after destroying it, an
  44.             error might occur in the naming of the new item.
  45.  
  46.           +o If you save a portion of a map containing nested loops,
  47.             and save both loop controllers but not the entire inner
  48.             loop, relaunching that map might cause the incorrect
  49.             module to be selected as the loop controller.
  50.  
  51.           +o When running an application with only maximized control
  52.             panels visible, selecting the Motif menu ``Close'' item
  53.             causes the control panel to go away, but the map
  54.             programs continue to run.  You must use the shell
  55.             command _p_s to find and destroy the processes.  Sending
  56.             a _k_i_l_l to the process named _g_u_i should suffice.  You
  57.             should define a ``Quit'' menu bar item to exit the
  58.             application, and then use it to exit the application.
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                                   - 2 -
  71.  
  72.  
  73.  
  74.  
  75.  
  76.        4.2  _F_i_r_i_n_g__A_l_g_o_r_i_t_h_m__A_n_o_m_a_l_i_e_s
  77.  
  78.           +o In version 2.1, widget values set programmatically
  79.             (e.g. with _c_x_I_n_W_d_g_t_D_b_l_S_e_t) would change the widget, but
  80.             would not change the port value if the _F_i_r_e _N_o_w menu
  81.             was selected.  This has been partially fixed.  The
  82.             correct value now appears on the port but the values
  83.             returned from _c_x_I_n_p_u_t_D_a_t_a_C_h_a_n_g_e_d and
  84.             _c_x_I_n_p_u_t_D_a_t_a_C_h_a_n_g_e_d_V may be inconsistent.  It is best to
  85.             assume that all widget values have changed.  Note that
  86.             the new widget values set programmatically were never
  87.             intended to appear on the port until the next time the
  88.             module fires.
  89.  
  90.           +o Button widgets are always marked as ``new data'' when a
  91.             module starts execution, even if the initialization
  92.             hook function calls _c_x_I_n_p_u_t_D_a_t_a_G_e_t on that port.
  93.  
  94.           +o Nested loops perform correctly in most cases, but
  95.             certain loop wirings can cause problems.  In
  96.             particular, a loop control module cannot receive data
  97.             both from within its loop and from within an inner
  98.             loop.  The data from the inner loop must be wired to
  99.             that loop's controller, then on to the outer loop
  100.             controller.  Routing all data through the inner
  101.             controller allows the inner controller to send
  102.             consistent control information to the outer loop
  103.             controller.
  104.  
  105.             In addition, if an outer controller receives data from
  106.             an inner loop, you must route all data going to the
  107.             outer controller through the inner controller. Failure
  108.             to do so causes the outer controller to receive data at
  109.             different loop nesting depths, which it might be unable
  110.             to handle.
  111.  
  112.  
  113.        4.3  _S_h_a_r_e_d__M_e_m_o_r_y__A_n_o_m_a_l_i_e_s
  114.  
  115.           +o If a module dies while allocating shared memory, it
  116.             locks the arena memory allocator, preventing other
  117.             module operations.  This has the appearance of the map
  118.             failing to fire after a module has died unexpectedly.
  119.             It is best to save your map and restart Explorer when
  120.             this happens.
  121.  
  122.           +o When the disk containing the shared memory arena fills
  123.             up during the execution of an Explorer map, there might
  124.             be no error reported, but the execution of the map
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                                   - 3 -
  137.  
  138.  
  139.  
  140.             stalls.  This condition will often only manifest itself
  141.             via system error messages in the console window.
  142.  
  143.  
  144.        4.4  _M_o_d_u_l_e__S_u_i_t_e
  145.  
  146.           +o Certain modules in Explorer version 2.2 are
  147.             incompatible with the dynamic shared objects (DSOs)
  148.             _l_i_b_c_x._s_o and _l_i_b_c_x_X._s_o in this release. However, all
  149.             such modules are authored by Silicon Graphics, are
  150.             included on this release, and are intended to be
  151.             installed to replace the previous distribution.
  152.  
  153.             In the event that you fail to replace the old module
  154.             during installation of Explorer 2.2.2, that module will
  155.             fail to start up the next time it is launched in the
  156.             Map Editor. The solution is to install the new module
  157.             from the 2.2.2 distribution of Explorer. Affected
  158.             modules include _A_n_n_o_t_a_t_i_o_n, _C_l_i_p_P_y_r, _D_i_s_p_l_a_y_I_m_g,
  159.             _I_L_C_o_n_t_r_o_l_l_e_r, _I_s_o_s_u_r_f_a_c_e_P_y_r, _S_l_i_c_e_P_y_r, _T_r_i_a_n_g_u_l_a_t_e_2_D,
  160.             and _T_r_i_a_n_g_u_l_a_t_e_3_D.
  161.  
  162.             Normally the old DSOs are distributed with each new
  163.             release of a system such as Explorer to prevent this
  164.             type of problem. But version 2.2 modules using the
  165.             version 2.2 _l_i_b_c_x_X._s_o are incompatible with the new
  166.             Motif DSO (which is _n_o_t being re-released as an
  167.             incompatible upgrade). Therefore, to ship the old
  168.             Explorer DSO would allow an old module (including those
  169.             written by users) to execute incorrectly. We choose
  170.             instead to make obsolete the above modules from version
  171.             2.2 and to replace the Explorer 2.2 DSOs with new ones.
  172.             With this approach there should be no adverse effects
  173.             on any user-written modules.
  174.  
  175.           +o The _R_e_n_d_e_r module puts its menus in the overlay planes
  176.             to avoid superfluous redraws. Due to a bug, these menus
  177.             may have an incorrect background color such as red or
  178.             black on 8-bit or pseudo-color visuals. When the
  179.             background color turns black it is the same as the
  180.             foreground color and the menu is unreadable.
  181.  
  182.             We have worked around this problem for _R_e_n_d_e_r pull-down
  183.             menus, at some cost in re-rendering of scenes, by
  184.             taking them out of the overlay planes.  However, the
  185.             button-3 pop-up menu remains in the overlay planes and
  186.             may become unreadable. If so, move the maximized _R_e_n_d_e_r
  187.             window around the screen; this seems to help clear up
  188.             the popup colormap temporarily. Or, if you have a 24-
  189.             bit system, use the TrueColor visual instead.
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                                   - 4 -
  203.  
  204.  
  205.  
  206.           +o In _R_e_n_d_e_r, Personal IRIS systems support only screen
  207.             door transparency.
  208.  
  209.           +o In _R_e_n_d_e_r, two-sided lighting does not work on IRIS
  210.             Indigo systems with Entry or XS graphics, even though
  211.             the systems have this capability.  This problem is
  212.             exhibited when the _R_e_n_d_e_r module is run on one system
  213.             and displays on a second, using DGL (distributed
  214.             graphics library).  This problem results in displays
  215.             that are completely dark on one side and correctly lit
  216.             on the other.
  217.  
  218.           +o In _R_e_n_d_e_r, selecting geometry objects received on the
  219.             Screen input port does not always work correctly.
  220.             Highlights and manipulators might be placed
  221.             incorrectly.  The Transform Sliders can be used to
  222.             position these objects accurately.
  223.  
  224.           +o The _R_e_n_d_e_r module is sensitive to some X Window System
  225.             application defaults.  For example, setting
  226.             ``*borderWidth:2'' causes the module to redraw itself
  227.             improperly when its window is resized.
  228.  
  229.           +o The _R_e_n_d_e_r module may print to standard output a terse
  230.             message of the form ``id XX not found,'' where XX is an
  231.             integer. This sometimes happens during disconnection of
  232.             a wire or destruction of a _R_e_n_d_e_r module. No action is
  233.             necessary.
  234.  
  235.           +o _R_e_n_d_e_r and other modules that receive geometry slowly
  236.             accumulate memory, possibly causing some fragmentation
  237.             of memory. The problem is that each Inventor scene
  238.             graph node has a name and the small names accumulate in
  239.             the process that transcribes in geometry.  The names
  240.             are now block allocated, so the fragmentation problem
  241.             isn't as severe as it was formerly, but it can still
  242.             cause problems if the module receives very large
  243.             geometries many times.  There is no workaround to this
  244.             problem, although we have increased the block size of
  245.             the names somewhat to push the failure point further
  246.             out.
  247.  
  248.           +o Some version 2.1 image processing modules (names end in
  249.             _I_m_g) may exit when run in the 2.2.2 Map Editor. Install
  250.             the new image processing modules from this
  251.             distribution.
  252.  
  253.           +o In _C_o_n_t_o_u_r, taking contours of large volumes with many
  254.             slices might consume excessive memory.
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                                   - 5 -
  269.  
  270.  
  271.  
  272.           +o The _G_e_n_e_r_a_t_e_C_o_l_o_r_m_a_p module does not compute ideal
  273.             control points for colormaps given all possible lattice
  274.             colormap inputs.  In particular, it might not place
  275.             control points close enough together if the input
  276.             lattice has discontinuities in one or more of the color
  277.             channels.
  278.  
  279.             Additionally, it might not pick ideal slopes for
  280.             control points even when given smooth inputs.
  281.  
  282.             The module sometimes produces a colormap with zero
  283.             opacity, resulting in completely transparent objects.
  284.             Refiring the module one or more times often resets the
  285.             opacity back to the desired values.
  286.  
  287.             When given input consisting of a step-function
  288.             colormap, the module represents the colormap
  289.             incorrectly. However, the output colormap is left
  290.             unmodified as long as you do not use _G_e_n_e_r_a_t_e_C_o_l_o_r_m_a_p's
  291.             colormap editing facilities.
  292.  
  293.           +o The _I_s_o_s_u_r_f_a_c_e_P_y_r module exits abnormally when given
  294.             the dataset /_u_s_r/_e_x_p_l_o_r_e_r/_d_a_t_a/_p_y_r_a_m_i_d/_s_h_u_t_t_l_e._p_y_r as
  295.             input. The module is unable to accept this form of
  296.             compressed input.
  297.  
  298.           +o In _L_a_t_F_u_n_c_t_i_o_n, an error pop-up might appear when no
  299.             data exists on an optional port that is referenced in
  300.             the Shape script.
  301.  
  302.           +o In _L_a_t_F_u_n_c_t_i_o_n, the Shape script might be incorrectly
  303.             interpreted when it is newly read after changing the
  304.             script file.  With the cursor in the Program file
  305.             type-in slot, press <Enter>; this causes _L_a_t_F_u_n_c_t_i_o_n to
  306.             reread the script and usually fixes the problem.
  307.  
  308.           +o If the _M_u_l_t_i_S_l_i_c_e module needs to readjust the Offset
  309.             widget back into the range of the number of slices on
  310.             its input, it does not recompute the slicing places.
  311.             You must adjust the Offset value manually to a valid
  312.             value for the module to recompute its output.
  313.  
  314.           +o Geometries saved by _W_r_i_t_e_G_e_o_m will not have the shape
  315.             hints normally used to view geometry in _R_e_n_d_e_r.
  316.             Therefore an Inventor scene graph saved via _W_r_i_t_e_G_e_o_m
  317.             and viewed with _i_v_v_i_e_w may not appear identical to the
  318.             same geometry viewed in _R_e_n_d_e_r.  Add to the saved
  319.             geometry the shape hints documented in the man page for
  320.             _R_e_n_d_e_r.
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                                   - 6 -
  335.  
  336.  
  337.  
  338.        4.5  _C_o_n_t_r_o_l__P_a_n_e_l__E_d_i_t_o_r
  339.  
  340.           +o The Control Panel Editor (CPE) does not retain all
  341.             information concerning a widget's properties when
  342.             switching between widgets.  If you change a widget from
  343.             a radio button to an option menu, the radio buttons'
  344.             labels are not applied to the new option menu.  This
  345.             occurs also for other widget combinations.
  346.  
  347.           +o Very long labels for Radio Button and Option Menu
  348.             widgets can confuse the CPE.  In this case, the editor
  349.             displays a long label, but the bank of option boxes is
  350.             incorrect, obscuring the buttons.
  351.  
  352.  
  353.        4.6  _M_o_d_u_l_e__B_u_i_l_d_e_r
  354.  
  355.           +o In the Connections panel, you cannot wire to any
  356.             lattice in the layers of a pyramid other than the
  357.             first.
  358.  
  359.           +o It is too easy to make wiring mistakes in the
  360.             Connections panel.  In particular, you can wire a (char
  361.             *) parameter value in a port to a (char) function
  362.             argument, resulting in a compile-time error if you let
  363.             the module builder create your function prototype.
  364.  
  365.           +o You cannot set the value of a constant wired to an
  366.             output port structure member.  Instead, wire the
  367.             constant to a function argument and from there to the
  368.             output port.
  369.  
  370.           +o Using strings as function parameters is confusing.  A
  371.             function argument in a C or C++ user function that is
  372.             to receive a character string from a parameter port
  373.             must be specified (in the Function Args panel) as type
  374.             ``char'' and reference ``Array.''  In a Fortran user
  375.             function, the function argument must be specified as a
  376.             ``character'' and a ``Scalar.''
  377.  
  378.           +o You can create a user-defined data type that contains
  379.             so many members that the menu for it in the Connections
  380.             panel is taller than the height of the screen.  If this
  381.             happens, apply the keyword ``closed'' to nested
  382.             structures within the new type; this prevents the
  383.             Module Builder from expanding them out in this menu.
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                                   - 7 -
  401.  
  402.  
  403.  
  404.        4.7  _D_a_t_a_S_c_r_i_b_e
  405.  
  406.           +o DataScribe does not handle tabs well when attempting to
  407.             read formatted input. The tab is treated as having a
  408.             fixed with (eg, 1 character) instead of padding out to
  409.             the next multiple of the tabbing width. If your data
  410.             file contains intermingled text, a formatted read is
  411.             the only way to skip the text. If this file also
  412.             contains tabs, the specified formatting will be
  413.             inconsistent with the file as read by Datascribe and a
  414.             core dump may ensue. The solution is to replace all
  415.             tabs with the correct (variable) number of spaces.
  416.             Datascribe will then read the file correctly.
  417.  
  418.           +o Under some circumstances the DataScribe will delete a
  419.             glyph's name (and replace it with an empty string) on
  420.             reading a DataScribe module.  Attempting to perform
  421.             wiring or array component selection in the presence of
  422.             an empty name may cause the DataScribe to dump core.
  423.  
  424.           +o In some cases using the Array Component glyph (the
  425.             cross-hatched green icon in a vector glyph) will cause
  426.             DataScribe to dump core.
  427.  
  428.           +o There are several minor annoyances in version 2.2.2 due
  429.             to design incompatibilities with Motif 1.2. Things such
  430.             as glyphs that appear the wrong size, incorrect window
  431.             sizing, etc, are due to this problem.  These problems
  432.             are typically minor and pose no impediment to correct
  433.             usage of the software.
  434.  
  435.           +o You can overlap templates in the DataScribe slightly.
  436.             This can occur under special circumstances if you close
  437.             and then open a template that is followed by another
  438.             open template.  If you save the module, clear the
  439.             DataScribe, then read in the script again, the overlap
  440.             disappears.  The overlap is slight and does not impair
  441.             use.
  442.  
  443.           +o Templates and glyphs must have unique names.  When you
  444.             append a template or glyph, you can create a script
  445.             with a duplicate name.  You must change the new
  446.             template or glyph names to avoid collisions with
  447.             existing components in the script.  The parser can, at
  448.             times, fail to detect the duplicate components.
  449.  
  450.           +o The value of the nDim glyph in an output lattice glyph
  451.             should not be altered.
  452.  
  453.           +o The response time is slow while editing names for
  454.             parameter glyphs because the CPE must be notified of
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                                   - 8 -
  467.  
  468.  
  469.  
  470.             changes during this processing. You do not need to
  471.             enter a carriage return when typing names and values in
  472.             the DataScribe; therefore, the CPE must process each
  473.             character separately.
  474.  
  475.           +o Glyph names must not include spaces. This can confuse
  476.             the parser.
  477.  
  478.           +o In the save pop-up dialog, if you select _O_K without
  479.             selecting or entering a filename, no prefix is assigned
  480.             and the files are saved with their default suffix only.
  481.  
  482.           +o In the Control Panel Editor, the _C_a_n_c_e_l button does not
  483.             cancel widget editing (that is, editing the widget
  484.             type, dimension, position), and it reverts back to the
  485.             beginning of the editing session.  Editing in the CPE
  486.             does not have any widget addition or deletion
  487.             semantics.  You can add and delete parameters only
  488.             through the DataScribe, not through the Control Panel
  489.             Editor.
  490.  
  491.           +o Drag-and-drop into output templates is unreliable if
  492.             the input pane has been hidden.  Glyphs can still be
  493.             added to the template by selecting the template, then
  494.             selecting the desired items in the palette while
  495.             holding down the <Alt> key.
  496.  
  497.  
  498.        4.8  _L_i_b_r_a_r_i_e_s__a_n_d__M_o_d_u_l_e__B_u_i_l_d_i_n_g__E_n_v_i_r_o_n_m_e_n_t
  499.  
  500.           +o Certain modules in Explorer version 2.2 are
  501.             incompatible with the dynamic shared objects (DSOs)
  502.             _l_i_b_c_x._s_o and _l_i_b_c_x_X._s_o in this release. However, all
  503.             such modules are authored by Silicon Graphics, are
  504.             included on this release, and are intended to be
  505.             installed to replace the previous distribution. See the
  506.             previous section "Module Suite" in this chapter for
  507.             more details.
  508.  
  509.           +o Linking modules that contain C++ source files gives a
  510.             linker warning indicating that the C++ library was not
  511.             used and could be removed from the link line. This
  512.             happens because the module control wrapper (MCW)
  513.             prelinks against the C++ library. No action is
  514.             necessary.
  515.  
  516.           +o Explorer modules are not marked for QuickStart by the
  517.             loader. You may observe a slightly longer startup time
  518.             than would have been possible with a quickstarting
  519.             executable.
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                                   - 9 -
  533.  
  534.  
  535.  
  536.           +o If you create a new data type with two unlabeled
  537.             members having the same name at the same scoping depth
  538.             from their shared parent types, the wrapper code
  539.             generator might try to call an API routine that doesn't
  540.             exist, resulting in a module compilation error.  The
  541.             workaround is to label the members with unique names or
  542.             change the member names so that they are unique.
  543.  
  544.           +o Using the Workshop Performance Analyzer tool on
  545.             Explorer modules is not currently supported.
  546.  
  547.           +o Modules written in Fortran that happen to call routines
  548.             from the Explorer Geometry API (eg, cxGeo* calls) may
  549.             exit when run. In these cases there will be no
  550.             resulting error message identifying the cause of the
  551.             module death. The module exits because a symbol is
  552.             undefined, but the situation is further confounded by
  553.             an absence of linker (ld) or run-time loader (rld)
  554.             error messages identifying the undefined symbol.
  555.  
  556.             Because Fortran modules call an interface routine found
  557.             in libcx.so or libcxX.so, which then calls the cxGeo
  558.             routine in libgeometry.a, the correct ordering of the
  559.             symbols on the link line is one of
  560.  
  561.                     userFunc.o -lcx  -lgeometry
  562.                     userFunc.o -lcxX -lgeometry
  563.  
  564.             Because User Library symbols are placed before the
  565.             Explorer system libraries on the link line, the actual
  566.             order reverses the cx and geometry libraries.  This
  567.             yields an undefined symbol at run time.
  568.  
  569.             The workaround is simple. Authors of Fortran geometry
  570.             modules must place the symbols
  571.  
  572.                     -L$(CXLIBDIR) $(LIBAPI)
  573.  
  574.             before $(GEOMETRYLIBS) in the User Libraries field of
  575.             the Module Builder main window. Authors of Fortran
  576.             geometry modules using X Windows must instead add the
  577.             symbols
  578.  
  579.                     -L$(CXLIBDIR) $(LIBAPI_X)
  580.  
  581.             For instance, a User Libraries line that read
  582.  
  583.                     $(GEOMETRYLIBS) mylib.a
  584.  
  585.             would now read as one of the following two lines,
  586.             depending on the absence or presence of X Windows code
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                                   - 10 -
  599.  
  600.  
  601.  
  602.             in the module:
  603.  
  604.                     -L$(CXLIBDIR) $(LIBAPI)   $(GEOMETRYLIBS) mylib.a
  605.                     -L$(CXLIBDIR) $(LIBAPI_X) $(GEOMETRYLIBS) mylib.a
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.